The present invention relates generally to traversal of a network address translator and, more particularly, to a scalable solution for traversing a symmetric network address translator for VoIP (VoIP) and other communication sessions.
The Internet is a global system of many interconnected computer networks, both public and private. The Internet allows direct end-to-end connectivity between two devices or end points using standard protocols such as the Internet Protocol (IP), Transmission Control Protocol (TCP), and User Datagram Protocol (UDP). Each device connected to the Internet is assigned an IP address which enables the routing of data packets. Currently, most devices use the address scheme specified in the Internet Protocol Version 4 (IPv4). The open architecture and near universal accessibility of the Internet has led to widespread adoption and use of the Internet by businesses and individuals.
The features that make the Internet so popular also contribute to some of its drawbacks. For example, the universal access and direct end-to-end connectivity enable users on opposite sides of the globe to communicate directly with one another, but exposes computers to hackers and other malicious third parties. The direct end-to-end connectivity also requires that each end device be given a unique IP address. However, the widespread adoption of the Internet has led to depletion of available addresses in the IPV4 address space.
To address security concerns, most private business and home networks now implement some form of firewall. A firewall comprises hardware and/or software that is designed to block unauthorized access to a protected network while permitting authorized communications with users outside the firewall. Firewalls protect against unauthorized access by applying a predefined security policy to packets entering a protected network. The security policy comprises a set of rules and procedures governing data packets entering or exiting the protected network. The firewall allows packets to pass through the firewall based on the specific rules of the defined policy. Most often, a firewall allows most outgoing packets originating inside the protected network to pass through the firewall while blocking most incoming packets from the public network. Data traffic from the public networks is allowed to pass only if it conforms to a defined access control filter, is sent in response to an outgoing data packet, or is part of an already-established communication session.
The problem of address exhaustion is typically handled by using a technique called network address translation (NAT). Network address translation is commonly implemented in conjunction with firewalls as part of an overall network security arrangement. Network address translation allows devices connected to a private network to share a single IP address. The basic idea behind network address translation is to assign private address from a private address space to devices connected to the private network. Because the private addresses use a different address space than the public Internet, packets containing a private address cannot be routed through the Internet. In order to allow a device with a private IP address to communicate with other devices on the Internet, a NAT (network address translator) translates private source and destination addresses of packets valid in the private address space to public source and destination addresses valid in the public address space.
There are many different NAT implementations, each affecting higher layer communication protocols differently. The present invention addresses problems with traversing symmetric NATs, although the invention may be used with other types of NAT implementations. In a symmetric NAT, each request from the same private IP address and port to a specific destination IP address and port is mapped to a unique public source IP address and port. If the same internal host sends a data packet with the same private source address and port, but to a different public IP address or port, a different mapping is used. In a symmetric NAT, data packets sent by an external host will be passed only if the internal host has previously Invited a response from the external host sending the data packet. Uninvited data packets from an external host will be blocked by the NAT.
While network address translation works well with many commonly used protocols, such as HTTP, POP, and SMTP, it may create problems for some application level communication protocols that send explicit network addresses within their payload. For instance, the Session Initiation Protocol (SIP) is a signaling protocol used to set up, maintain, and terminate voice-over IP (VoIP) sessions. A typical VoIP application will use different addresses and/or ports for signaling traffic and media traffic such as voice, video, and fax traffic. To set up the VoIP session, the call originator invites the called party to participate in a call by sending a SIP INVITE request. The called party accepts the invitation by sending a SIP RESPONSE message. The SIP INVITE and SIP RESPONSE messages typically include specific addresses and ports that are being opened for the RTP (media) traffic.
In the case where the called party is behind a symmetric NAT, the SIP INVITE request will be blocked by the NAT and never reach the called party. Even if the called party is reachable, the SIP Response from called party may be blocked in situations where the calling party is behind a symmetric firewall/NAT. Further, the VoIP application will typically use a different IP address and port for sending and receiving RTP or RCTP traffic, e.g., voice data. The VoIP client has no way of knowing the external address assigned by the NAT for the RTP and RTCP traffic.
A number of techniques have been used to solve the NAT traversal problem for voice-over IP communications. One solution is to use an application level gateway (ALG). An application level gateway is a software component that allows examination and modification of data packets passing through the NAT. In the case of SIP protocol packets, the ALG can replace private source and destination addresses contained in the payload of SIP messages with public source and destination addresses. This technique does not ensure security or authenticity and is difficult to deploy because the ALG must have knowledge of the application level protocols. Thus, a separate ALG is typically required for each application.
A network protocol called STUN (Session Traversal Utilities for NAT) described in RFC 5389 allows a host device in a private network to discover the presence of a network address translator and to obtain the public NAT address that was allocated for the user's UDP connection to a remote host. A client device generates and sends a STUN request to a STUN application server in the public network prior to setting up communication with a remote host. The request causes the NAT to allocate a public address and create a binding between the public address and the private source address of the STUN request. The STUN application server sends a STUN response to the client and, within its payload, returns the public NAT address allocated by the NAT. The client may then advertise this public address as the address on which it will receive UDP packets (both for signaling and media packets). The STUN protocol does not work with a symmetric firewall in situations where the client will be receiving packets from public addresses other then the public address of the STUN application server.
A protocol called TURN (Traversal Using Relay NAT) provides an application server function to a client behind a NAT to allow the client to receive incoming data over TCP or UDP connections. Similar to STUN, a client sends a request to a TURN application server prior to setting up communication with a remote host. The TURN application server returns to the client the address that it can use as the destination for media, which the client uses as the destination address for packets sent to the remote host. The destination address returned is not the address of the remote host, but instead, is an address associated with the TURN application server. The TURN application server acts as a relay and forwards the packet. Although TURN provides a solution to the NAT traversal problem, it requires that all packets be relayed by the TURN application server, and thus is not easily scalable. While network delays induced by the introduction of additional network hops is typically not significant enough to affect the SIP signaling, media packets should be delivered with minimal delays. Therefore, a solution that reduces the number of hops, and therefore the overall delay, is preferable.
A session border controller (SBC) is a device used in some VoIP networks to traverse a network address translator. The SBC is a session-aware device that provides both media proxy and session control functions. The SBC is essentially a proxy that establishes call legs in two different networks. The SBC receives packets on one call leg and forwards them toward the destination on the other call leg. Because the SBC modifies the addresses, it may break some security mechanisms. Also, session border controllers are expensive, difficult to deploy, and not easily scalable because all packets must be relayed through the SBC.